Remarks 



I. 35 USC U 12 

A. 35 USC § 112,1(1 

Claims 1, 21 and 28 stand rejected under 35 USC §1 12, f 1, as allegedly failing to 
comply with the written description requirement. In this regard, the Final Rejection 
states: 

2. Claims 1, 21, 28 are rejected under 35 U.S.C. 112(a) or 35 
U.S.C. 112 (pre-AlA), first paragraph, as failing to comply with the 
written description requirement. The claim(s) contains subject matter 
which was not described in the specification in such a way as to 
reasonably convey to one skilled in the relevant art that the inventor or a 
joint inventor, or for pre-AlA the inventor(s), at the time the application 
was filed, had possession of the claimed invention. 

3. It is unclear how Specification, page 11, lines 18-21 discloses 
"wherein said data corresponds to a layer higher than said transport layer". 
Please clarify or amend claims accordingly. 

4. It is unclear how Specification, page 11, lines 1-5, 18-21 
discloses "associating ... said TCP connection with said file cache". Please 
clarify or amend claims accordingly. 

Applicants respectfully submit that the Final Rejection has, by only providing 
merely conclusory statements, failed to satisfy its burden to articulate a prima facie case. 
Without adequate notice of the basis of this rejection, the burden to rebut this rejection 
with evidence and/or argument has not yet shifted to applicants. 

The MPEP repeatedly warns that the Office bears an initial burden of establishing 
a prima facie case when making a written description rejection. MPEP §§ 706.07, 2163 
(III) (A). A prima facie case requires a reasonable basis to challenge the adequacy of the 
written description. MPEP § 2163.04. The MPEP equates this reasonable basis with "a 
preponderance of evidence why a person skilled in the art would not recognize in an 
applicant's disclosure a description of the invention defined by the claims." MPEP § 
2163(III)(A). Consequently, the Office must provide a reasonable basis to reject a claim 
for failing to satisfy the written description requirement, and this requires "a full 
development" of the reasons showing that, by a preponderance of the evidence, a person 
of ordinary skill in the art would not recognize a description of the claimed invention in 
the disclosure. In this regard, the MPEP expressly instructs that merely conclusory 
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statements are insufficient. Rather, every written description rejection "should be stated 
with a full development of the reasons rather than by a mere conclusion. . . ." MPEP § 
706.03. Stated another way, the Office must adequately explain the perceived 
shortcomings of the application so that an applicant is properly notified and able to 
respond. Finally, until the Office establishes a prima facie case, an applicant is not under 
an obligation to rebut the rejection. MPEP § 2163.04. Applicants respectfully submit that 
such is the case here. 

The written description rejection is quoted in its entirety above, and merely states 
it is "unclear" how parts of the specification disclose the claimed recitations. Absent 
from this rejection, for example, are any "reasoned or supported statements" supporting 
this rejection, as the MPEP expressly requires. Indeed, the rejection is devoid of 
"evidence or reasons" as to why the disclosure fails to reasonably convey to one of 
ordinary skill in the art that applicants possessed the claimed invention. Thus, the Office 
has failed to set forth express findings of fact that support the lack of written description 
conclusion as its own procedures require. MPEP §2163.04. Rather, the provided 
"reason" is a mere conclusion, which the MPEP expressly warns is insufficient to support 
this rejection. MPEP § 706.03. 

The Office's failure to meet its burden to articulate a "reasonable basis 
challenging the adequacy of the written description" with "findings of fact" is fatal to this 
rejection since applicants are under no burden to rebut it. MPEP §§ 706.07, 2163, 
2163.04. For this reason, this rejection is traversed. 

In the event that the Office maintains this rejection, applicants respectfully 
request, in accordance with the principles of compact prosecution, that the Office fully 
develop the reasons for this rejection by articulating, on the record, "properly reasoned 
and supported statements" that sufficiently explain what, in the Examiner's view, is 
missing from the written description. 

Notwithstanding the lack of a prima facie rejection, in an effort to expedite the 
lengthy prosecution of this application, applicants respond below to the rejection as best 
understood. 

Regarding the Final Rejection assertion that "It is unclear how Specification, page 
1 1, lines 18-21 discloses 'wherein said data corresponds to a layer higher than said 
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transport layer,'" applicants are surprised that the Examiner does not recognize the 
abundant support in the specification for this recitation. In addition to applicants' 
previous citation, please see page 9, line 28 - page 10, line 1 1 ; page 10, line 30 - page 
11, line 5; and page 48, line 28 - page 50, line 2, for example. 

When a disclosure describes a claimed invention in a manner that permits one 
skilled in the art to reasonably conclude that the inventor possessed the claimed invention 
the written description requirement is satisfied. MPEP §2163. This possession may be 
shown in any number of ways and an applicant need not describe every claim feature 
exactly because there is no in haec verba requirement. MPEP § 2163. Rather, to satisfy 
the written description requirement, all that is required is "reasonable clarity." MPEP § 
2163.02. Also, an adequate description may be made in any way through express, 
implicit, or even inherent disclosures in the application, including words, structures, 
figures, diagrams, and/or formulae. MPEP §§ 2163(1), 2163.02. 

Regarding the Final Rejection assertion that "It is unclear how Specification, page 
11, lines 1-5, 18-21 discloses 'associating ... said TCP connection with said file cache,'" 
applicants are once again surprised that the Examiner does not recognize the support in 
the specification for this recitation. In addition to applicants' previous citation, please see 
page 10, lines 14-23; and page 11, lines 5-18; page 14, lines 4-20, for example. 

Moreover, applicants respectfully note that claim 28 does not even contain the 
recitations for which the Final Rejection alleges support is "unclear." 

Accordingly, applicants respectfully request favorable reconsideration and 
withdrawal of the rejection of claims 1,21 and 28 under the first paragraph of 35 USC § 
112. 

B. 35 USC § 112, Tf 2 

Claims 1, 21 and 28 stand rejected under 35 USC §1 12, f 2, as allegedly being 

indefinite. In this regard, the Final Rejection states: 

6. Claims 1, 21, 28 are rejected under 35 U.S.C. 112(b) or 35 
U.S.C. 112 (pre-AlA), second paragraph, as being indefinite for failing to 
particularly point out and distinctly claim the subject matter which the 
inventor or a joint inventor, or for pre-AlA the applicant regards as the 
invention. 
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7. Claims 1, 21, 28 recite the limitation "said memory". There is 
insufficient antecedent basis for this limitation in the claim. Examiner 
suggests "said interface memory" as correction. 

As with the written description requirement, the MPEP states that the Office bears 
an initial burden of establishing a prima facie case when making an indefmiteness 
rejection. MPEP §§ 706.07, 2173. "[S]uch rejections must clearly identify the language 
that causes the claim to be indefinite and thoroughly explain the reasoning for the 
rejection." MPEP § 2173. "Thus, when a rejection under 35 U.S.C. 1 12, second 
paragraph, is appropriate based on the examiner's determination that a claim term or 
phrase is indefinite, the examiner should clearly communicate in an Office action any 
findings and reasons which support the rejection and avoid a mere conclusion that the 
claim term or phrase is indefinite. See MPEP § 706.03, 707.07(g). . .Only by providing a 
complete explanation in the Office action as to the basis for determining why a particular 
term or phrase used in the claim is 'vague and indefinite' will the examiner enhance the 
clarity of the prosecution history record." MPEP § 2173(III)(A). Thus, an indefmiteness 
rejection "should be stated with a full development of the reasons rather than by a mere 
conclusion...." MPEP § 706.03. 

The indefiniteness rejection is quoted in its entirety above, and merely states that 
there is insufficient antecedent basis for the limitation "said memory," and "suggests 
'said interface memory' as correction." Any reason for the alleged lack of antecedent 
basis is lacking, and, as explained below, is not apparent from the claim language. 

The term "said memory" closely follows the term "an interface memory" in the 
claimed recitation, so it is quite clear what "memory" is being recited. Indeed, there is no 
other "memory" recited in the claims, so there can be no confusion. Moreover, it has 
long been common practice to refer to a shortened version of a claim term after 
introducing the term in full. As but one of many examples, claim 1 of In re Donaldson 
Co., Inc., 16 F.3d 1 189 (Fed. Cir. 1984) begins with "An air filter assembly. . .for filtering 
air laden with particulate matter, said assembly. . .comprising:" and also recites "a 
plurality of spaced-apart filter elements. . .within said filtering chamber. . ., with each of 
said elements ... being in fluid communication with said air outlet." Id. at 1191. 
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Perhaps the Final Rejection has confused the order in which the claim terms are 

recited. As noted in MPEP 2173.05(e): 

A claim which refers to "said aluminum lever," but recites only "a 
lever" earlier in the claim, is indefinite because it is uncertain as to the 
lever to which reference is made. Obviously, however, the failure to 
provide explicit antecedent basis for terms does not always render a claim 
indefinite. If the scope of a claim would be reasonably ascertainable by 
those skilled in the art, then the claim is not indefinite. 

Applicants agree that, had the claim recited "a memory" followed by "said 
interface memory," the claim might be indefinite. In the present case, however, there is 
not such uncertainty as to the meaning of the claim terms. 

As stated in MPEP § 2173(11): 

The examiner's focus during examination of claims for compliance 
with the requirement for definiteness of 35 U.S.C. 112, second paragraph, 
is whether the claim meets the threshold requirements of clarity and 
precision, not whether more suitable language or modes of expression are 
available. When the examiner is satisfied that patentable subject matter is 
disclosed, and it is apparent to the examiner that the claims are directed to 
such patentable subject matter, he or she should allow claims which define 
the patentable subject matter with a reasonable degree of particularity and 
distinctness. Some latitude in the manner of expression and the aptness of 
terms should be permitted even though the claim language is not as precise 
as the examiner might desire. Examiners are encouraged to suggest claim 
language to applicants to improve the clarity or precision of the language 
used, but should not reject claims or insist on their own preferences if 
other modes of expression selected by applicants satisfy the statutory 
requirement. 

Moreover, applicants respectfully note that claim 28 does not even contain the 
recitation which the Final Rejection alleges are indefinite. 

For all these reasons, applicants respectfully request favorable reconsideration and 
withdrawal of the rejection of claims 1,21 and 28 under the second paragraph of 35 USC 
§112. 



II. 35 USC § 103 

A. Claims 1, 4, 6-7, 21, 23-24 and 26-33 

Claims 1, 4, 6-7, 21, 23-24 and 26-33 stand rejected under 35 U.S.C. §103(a) as 
allegedly being obvious over U.S. Patent No. 6,427,169 to Elzur ("Elzur") in view of 
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U.S. Patent No. 4,625,081 to Lotito et al. ("Lotito"), and in further view of U.S. Patent 

No. 6,453,360 to Muller et al. ("Muller"). 

1. Claims 1 and 21 

Regarding claims 1 and 21, the Office Action states: 

As per claim 1, 21, Elzur discloses an interface device for a 
computer having a file system that controls a file cache, the interface 
device comprising: 

• interface hardware configured to process a transport layer 
header of a packet received via a first physical network port, and to 
separate said transport layer header from data of said packet, wherein said 
data corresponds to a layer higher than said transport layer (column 1, 
lines 18-21, column 2, lines 55-67, column 3, lines 1-3, 46-51, 57-67, 
column 4, lines 1, 6-11, column 5, lines 63-66; A network controller, at 
the physical layer, establishes physical communication with the network to 
send and receive packets to and from the network); 

• An interface memory storing a TCP connection established by 
the computer and handled by said device (column 4, lines 14-17, 23-25, 
34-36, 61-67, column 5, lines 63-66, column 7, lines 1-5, ; The network 
controller includes hardware such as a receive path. The receive path 
includes a memory that stores flow tuples that identify characteristics of a 
particular flow associated with a TCP connection); 

• An interface mechanism for associating said packet with said 
TCP connection (column 4, lines 14-17, 23-25, 34-36, 61-67, column 5, 
lines 14-24). 

Elzur does not explicitly disclose: 

• to send data from said packet via a second physical network 
port to a storage unit, thereby avoiding the computer. 

However in an analogous art, Lot discloses a packet switcher 
testing a physical address input port for availability to receive a packet of 
data. If available, the packet is transferred. The header of the packet 
determines process identification. Some data is transferred between user 
processes and buffers in the device, controller, or handler. However, a user 
process can initiate a transfer of data between source and destination 
without passing the data through the user's process. For example, a 
transfer can go from a display record on disk to an operator station with no 
intervention from user and with direct routing of the data through the 
system. No processing occurs (column 17, lines 24-27, column 45, lines 
20-34, column 67, lines 49-55, column 68, lines 5-17, column 114, lines 
37-47). 

Therefore, one of ordinary skill in the art at the time the invention 
was made would have found it obvious to implement or incorporate Lot's 
send data via a second physical network port to a storage unit, thereby 
avoiding the computer in Elzur's device enabling data to be transferred 
without processing. 
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Elzur, in view of Lot, does not explicitly disclose: 

• said memory adapted to store said data in said file cache; 

• said TCP connection with said file cache. 

However, the use and advantages for using such a file cache is 
well-known to one of ordinary skill in the art as evidenced by Muller 
(column 56, lines 20-30, column 57, lines 55-65, column 58, lines 26-30, 
column 59, lines 60-65). 

Therefore, one of ordinary skill in the art at the time the invention 
was made would have found it obvious to implement or incorporate 
Muller's file cache in Elzur's device in order to store non-assembled 
packets. 

Applicants respectfully assert that the Final Rejection fails to set forth a prima 
facie case of obviousness for any of the pending claims, as shown below. Applicants 
note that the Final Rejection groups together the rejections of claims 1 and 21, but only 
specifically addresses the recitations of claim 1 . Because the Final Rejection fails to set 
forth a prima facie case of obviousness for either claim, applicants first rebut the 
rejection as presented, and then discuss additional deficiencies in the rejection of claim 
21. 

The MPEP notes that the Office bears an initial burden of establishing a prima 
facie case when making an obviousness rejection. MPEP §§2141, 2142. Applicants 
respectfully submit that the Final Rejection has, by providing at most merely conclusory 
statements, failed to satisfy its burden to articulate a prima facie case. Without adequate 
notice of the basis of this rejection, the burden to rebut this rejection with evidence and/or 
argument has not yet shifted to applicants. 

In order to establish a prima facie case of obviousness, the scope and content of 
the prior art, the level of ordinary skill in the art at the time of the invention, and the 
differences between the prior art and the claim must first be ascertained, and then the 
Examiner must show that the claim would have been obvious to one of ordinary skill in 
the art at the time of the invention. Graham v. John Deere Co., 383 U.S. 1, 17 (1966). 
The Final Rejection, in contrast, fails to address the scope and content of the prior art for 
all of the claimed recitations, fails to set forth the level of ordinary skill in the art, fails to 
interpret the claims and consequently fails to address the differences between the prior art 
and the claims, and fails to provide more than merely conclusory statements as to its 
conclusion of obviousness. 
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The failure of the Final Rejection to present a prima facie case of obviousness 



begins with its first obviousness allegation, which states: "As per claim 1,21, Elzur 

discloses an interface device for a computer having a file system that controls a file 

cache." The Final Rejection offers no evidence or explanation as to how "Elzur 

discloses. . .a file system that controls a file cache." A "file system" is not mentioned 

anywhere in Elzur. A "file cache" is not mentioned anywhere in Elzur. For at least this 

reason, the Final Rejection has failed to present a prima facie case of obviousness. 

On pages 12-14, the Final Rejection provides a "Response to Arguments" section 

which states in part: 

The Office notes the following argument(s): 
(a) Regarding claims 1, 21, 28, there appears to be no mention of a 
"file system" or "file cache" in either Elzur or Lotito. 

In response to: 

(a) Applicant's arguments have been considered but are moot 
because the arguments do not apply to any of the references being used in 
the current rejection. 

As noted above, however, the Final Rejection, like the two prior Office Actions, 
begins by asserting that "Elzur discloses. . .a file system that controls a file cache." As 
noted in applicants' prior response, the present application states, beginning at page 8, 
lines 24-31: 

The file system 23 is a high level software entity that contains 
general knowledge of the organization of information on storage units 66 
and 70 and file caches 24 and 80, and provides algorithms that implement 
the properties and performance of the storage architecture. The file 
system 23 logically organizes information stored on the storage units 66 
and 70, and respective file caches 24 and 80, as a hierarchical structure of 
files, although such a logical file may be physically located in disparate 
blocks on different disks of a storage unit 66 or 70. The file system 23 
also manages the storage and retrieval of file data on storage units 66 and 
70 and file caches 24 and 80. 

Similarly, none of the references cited to allege obviousness teaches or suggests 
"an interface mechanism for associating . . . said TCP connection with said file cache. . ." 
as recited in claim 1. This point was made in applicants' prior response, which applicants 
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The Office notes the following argument(s): 

(b) Muller does not teach or suggest "an interface memory ... 
adapted to store said data in said file cache" as recited in claim 1. 

In response to: 

(b) Applicant's arguments filed have been fully considered but they 
are not persuasive. 

Muller teaches a Network File System (NFS) application, data 
portion may include NFS headers related to individual NFS datagrams. A 
datagram is defined as a collection of data sent from one entity to another 
and may comprise data transmitted in multiple packets. The Network 
Interface Circuit (NIC) uses header information to process the packet as 
well as NFS file handles. The NIC has a processor and memory to process 
and store packet information. Buffers the size of a memory page are used 
to assemble data (column 11, lines 52-59, column 12, lines 15-20, column 
15, lines 19-25, column 16, lines 59-61, column 23, lines 18-30, column 
26, lines 15-20, column 54, lines 32-43, column 56, lines 20-30, column 
57, lines 55-65, column 58, lines 26-30, column 59, lines 60-65). 

Therefore, Muller undoubtedly discloses "an interface memory ... 
adapted to store said data in said file cache" as recited in claim 1 . 

The "Network File System (NFS) application" taught by Muller is not, however, 
"a high level software entity that contains general knowledge of the organization of 
information on storage units 66 and 70 and file caches 24 and 80, and provides 
algorithms that implement the properties and performance of the storage architecture." 
Further, unlike the file system of the present invention, NFS does not "logically 
organize. . . information stored on the storage units 66 and 70, and respective file caches 
24 and 80, as a hierarchical structure of files, although such a logical file may be 
physically located in disparate blocks on different disks of a storage unit 66 or 70." In 
addition, unlike the file system of the present invention, NFS does not " manage. . . the 
storage and retrieval of file data on storage units 66 and 70 and file caches 24 and 80." 

Moreover, the "Buffers the size of a memory page" that "are used to assemble 
data" are indeed pages of memory on the host computer, not the "interface memory" of 
the "interface device" recited in claim 1 . Instead, the "The Network Interface Receive 
Circuit" shown in FIG. 1 A of Muller includes "packet queue 116" for holding packets 
received from the network. Thus Muller also does not disclose "an interface memory. . . 
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adapted to store said data in said file cache," for "a computer having a file system that 

controls (the) file cache," as recited in claim 1. 

The present application continues the description of the file system and file cache 

at page 8, line 3 1- page 9, line 9, which states: 

I/O driver 67 software operating on the host 20 under the file 
system interacts with controllers 64 and 72 for respective storage units 66 
and 70 to manipulate blocks of data, i.e., read the blocks from or write the 
blocks to those storage units. Host file cache 24 and INIC file cache 80 
provide storage space for data that is being read from or written to the 
storage units 66 and 70, with the data mapped by the file system 23 
between the physical block format of the storage units 66 and 70 and the 
logical file format used for applications. Linear streams of bytes 
associated with a file and stored in host file cache 24 and INIC file cache 
80 are termed file streams. Host file cache 24 and INIC file cache 80 each 
contain an index that lists the file streams held in that respective cache. 

In contrast, the paragraph of Muller that includes the Office Action citation of 

column 56, lines 20-30 states: 

With reference back to FIGS. 1A-B, a packet that is to be 
transferred into host memory by DMA engine 120 is stored in packet 
queue 116 after being received from network 102. Header parser 106 
parses a header portion of the packet and generates a flow key, and flow 
database manager 108 assigns an operation code to the packet. In addition, 
the communication flow that includes the packet is registered in flow 
database 110. The packet's flow may be identified by its flow key or flow 
number (e.g., the index of the flow in flow database 110). Finally, 
information concerning the packet (e.g., operation code, a packet size 
indicator, flow number) is stored in control queue 118 and, possibly, other 
portions or modules of NIC 100, and the packet is transferred to the host 
computer by DMA engine 120. During the transfer process, the DMA 
engine may draw upon information stored in the control queue to copy the 
packet into an appropriate buffer, as described below. Dynamic packet 
batching module 122 may also use information stored in the control queue, 
as discussed in detail in a following section. 

This disclosure of "a packet that is to be transferred into host memory by DMA 

engine 120 is stored in packet queue 116" does not teach or suggest a file cache disposed 

on an interface device. Similarly, the paragraph of Muller that includes the Office Action 

citation of column 58, lines 26-30 states: 

In the illustrated embodiment of the invention, data portions of 
related, re-assembleable, packets are placed into a first category of 
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buffers-which may be termed re-assembly buffers. A second category of 
buffers, which may be called header buffers, stores the headers of those 
packets whose data portions are being re-assembled and may also store 
small packets (e.g., those less than or equal to 256 bytes in size). A third 
category of buffers, MTU buffers, stores non-re-assembleable packets that 
are larger than 256 bytes, but no larger than MTU size (e.g., 1522 bytes). 
Finally, a fourth category of buffers, jumbo buffers, stores jumbo packets 
(e.g., large packets that are greater than 1522 bytes in size) that are not 
being re-assembled. Illustratively, a jumbo packet may be stored intact 
(e.g., its headers and data portions kept together in one buffer) or its 
headers may be stored in a header buffer while its data portion is stored in 
an appropriate (e.g., jumbo) non-re-assembly buffer. 

This disclosure that "data portions of related, re-assembleable, packets are placed 
into a first category of buffers—which may be termed re-assembly buffers," teaches 
reassembly at the TCP level, not at the level of a file cache under control of a file system. 
Moreover, Muller teaches that such buffers are located in host computer memory, not in 
an interface device. See, e.g., column 56, lines 34-38. 

In short, Muller does not teach or suggest an "interface device for a computer 
having a file system that controls a file cache," does not teach or suggest "an interface 
memory . . . adapted to store said data in said file cache," and does not teach or suggest 
"an interface mechanism for associating . . . said TCP connection with said file cache. . ." 
as recited in claim 1 . 

Applicants note that the Final Rejection has added a couple of citations from 
Muller to those set forth in the prior Office Action as purportedly disclosing the recitation 
of "an interface memory . . . adapted to store said data in said file cache," to wit, "column 
57, lines 55-65" and "column 59, lines 60-65." 

Column 57, lines 55-65 of Muller states: 

Free ring manager 1012 attempts to ensure that a buffer is always 
available for a packet. Thus, in one embodiment of the invention free ring 
manager 1012 includes descriptor cache 1012 a configured to store a 
number of descriptors (e.g., up to eight) at a time. Whenever there are less 
than a threshold number of entries in the cache (e.g., five), additional 
descriptors may be retrieved from the free descriptor ring. 
Advantageously, the descriptors are of such a size (e.g., sixteen bytes) that 
some multiple (e.g., four) of them can be efficiently retrieved in a sixty- 
four byte cache line transfer from the host computer. 

Column 59, lines 60-65 of Muller states: 
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...associated with NIC 100). In one embodiment of the invention, 
completion ring manager 1014 includes completion descriptor cache 
1014a. Completion descriptor cache 1014a may store one or more 
completion descriptors for collective transfer from DMA engine 120 to the 
host computer. 

It is difficult to understand why the Final Rejection includes these citations as 
they appear to be unrelated to the claimed recitation, and the Final Rejection offers no 
explanation as to their relevance. For at least this additional reason, the Final Rejection 
has failed to present a prima facie case of obviousness. 

Further, the Final Rejection admits that "Elzur, in view of Lot, does not explicitly 
disclose: . . .said TCP connection with said file cache." The Final Rejection then alleges 
that "the use and advantages for using such a file cache is well-known to one of ordinary 
skill in the art as evidenced by Muller," citing the portions of Muller quoted above. 

Nothing in those portions of Muller, however, disclose "an interface mechanism 
for associating said packet with said TCP connection and said TCP connection with said 
file cache." 

In other words, the Final Rejection lumps together the rejection of two separate 
claim recitations in order to reject those recitations over portions of Muller that disclose 
neither of the recitations. Moreover, it is not even clear what is meant by the Final 
Rejection assertion that Muller discloses "said TCP connection with said file cache." 
Stated differently, the Final Rejection does not even assert that any of the references 
discloses the claimed recitation of "an interface mechanism for associating. . . said TCP 
connection with said file cache." 

For at least these additional reasons, the Final Rejection has failed to present a 
prima facie case of obviousness. 

In addition to the above-discussed failure to show the scope and content of the 
prior art, the Final Rejection fails to set forth the level of ordinary skill in the art, and for 
this reason also the Final Rejection fails to present a prima facie case of obviousness. 

The Final Rejection also fails to provide an interpretation of the claims, and for 
this reason also the Final Rejection fails to present a prima facie case of obviousness. 
The MPEP repeatedly teaches that, to provide a prima facie case of obviousness, the 
Examiner must interpret the claims. "The scope of the claimed invention must be clearly 
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determined by giving the claims the 'broadest reasonable interpretation consistent with 
the specification.'" MPEP § 2141(II)(A)(citations omitted). "Ascertaining the 
differences between the claimed invention and the prior art requires interpreting the claim 
language. . ." MPEP §§ 2141 (H)(B), 2141.02. Thus, the Final Rejection fails to 
adequately perform yet another of the basic factual inquiries required by Graham v. John 
Deere Co. 

Because, as detailed above, the Final Rejection fails to adequately perform every 
one of the basic factual inquiries required by Graham, it follows that any conclusion of 
obviousness that is based on the Final Rejection's factual findings is also flawed. 
However, in addition to failing to adequately perform every one of the factual inquiries 
by Graham, the Final Rejection also offers merely conclusory statements to support its 
assumption that the claims are obvious. 

For example, beginning with the premise, disproved above, that "the use and 
advantages for using such a file cache is well-known to one of ordinary skill in the art as 
evidenced by Muller," the Final Rejection concludes that "one of ordinary skill in the art 
at the time the invention was made would have found it obvious to implement or 
incorporate Muller's file cache in Elzur's device in order to store non-assembled packets." 
Even if this were true it does not address the claimed recitations of "An interface device 
for a computer having a file system that controls a file cache, the interface device 
comprising: . . .an interface memory . . . adapted to store said data in said file cache." 
There is simply no consideration anywhere in the Final Rejection and no teaching or 
suggestion in the cited art of the idea of a file cache on an interface device memory in 
which the file cache is controlled by the file system of the computer. 

Moreover, instead of considering the invention as a whole, the Final Rejection 
cobbles together bits and pieces of various references that inadequately describe portions 
of the claims, and then jumps to the conclusion that the claims are obvious. 

As noted above, the Final Rejection groups together the § 103 rejections of claims 
1 and 21, despite differing recitations of the claims. For example, the Final Rejection 
does not specifically address the following recitations in claim 21 : "an interface receive 
mechanism that processes a Transmission Control Protocol (TCP) header of a network 
packet," "an interface memory storing an established TCP connection that can migrate to 
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and from the computer, said memory storing said data in said file cache," and "an 
interface processing mechanism that associates said packet with said TCP connection and 
said TCP connection with said file cache to send said data from said packet via a physical 
network port to a storage unit, thereby avoiding the computer." For at least these 
additional reasons, the Final Rejection does not state a prima facie case of obviousness 
for claim 21. 

For all the above reasons, applicants respectfully assert that the Final Rejection 
fails to present a prima facie case of obviousness for claims 1 and 21 or for any claim that 
depends from either of those claims. 

2. Claim 4 

Regarding claim 4, the Final Rejection states: 

As per claim 4, Elzur discloses the interface device of claim 1, 
further comprising a Fibre Channel controller connectable to the storage 
unit (column 3, lines 46-60). 

Applicants respectfully disagree. A "Fibre Channel controller" is not disclosed in 
column 3, lines 46-60 of Elzur. A "Fibre Channel controller" is also not disclosed 
elsewhere in that patent, and is not disclosed in Lotito or Muller. 

Applicants respectfully note that the Final Rejection of claim 4 simply repeats the 
prior rejection, even though the rejection was rebutted in applicants' prior response, and 
for this additional reason the Final Rejection fails to present a prima facie case of 
obviousness for claim 4. 

3. Claims 6 and 26 

Regarding claims 6 and 26, the Final Rejection states: 

As per claims 6, 26, Elzur, in view of Lot, does not explicitly 
discloses the network interface device of claim 1, wherein said file cache 
is adapted to store said data as a file stream, and the interface device is 
adapted to send said data as file blocks for storage on the storage unit. 

However, the use and advantages for using such file cache to store 
and interface device to send data as blocks is well-known to one of 
ordinary skill in the art as evidenced by Muller (column 15, lines 19-25, 
column 16, lines 57-61, column 21, lines 27-34, 40-41, column 24, lines 
29-38). 
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Therefore, one of ordinary skill in the art at the time the invention 
was made would have found it obvious to implement or incorporate 
Muller's file cache in Elzur's device in order to store non-assembled 
packets. 

Applicants respectfully disagree. For convenience, the portions of Muller cited 

by the Final Rejection are quoted in order below: 

For example, for a Network File System (NFS) application, data 
portion 202 may include NFS headers related to individual NFS 
datagrams. A datagram may be defined as a collection of data sent from 
one entity to another, and may comprise data transmitted in multiple 
packets. In other words, the amount of data constituting a datagram may 
be greater than the amount of data that can be included in one packet. 

Other indicia of the communicating entities may be used, such as 
the Ethernet source and destination addresses (drawn from the layer two 
header), NFS file handles or source and destination identifiers for other 
application datagrams drawn from the data portion of the packet. 

The Total Length field stores the size of the IP segment of this 
packet, which illustratively comprises the IP header, the TCP header and 
the packet's data portion. The TCP segment size of the packet (e.g., the 
size of the TCP header plus the size of the data portion of the packet) may 
be calculated by subtracting twenty bytes (the size of the IP version four 
header) from the Total Length value. After state 416, the illustrated 
procedure advances to state 422. 

In state 420, the values of the Payload Length (e.g., the size of the 
TCP segment) and Next Header field are saved, plus the IP source and 
destination addresses. 

For example, a set of instructions could be generated for parsing 
NFS (Network File System) packets. Illustratively, these instructions 
would be configured to parse layer five and six headers to determine if 
they are Remote Procedure Call (RPC) and External Data Representation 
(XDR), respectively. Other instructions could be configured to parse a 
portion of the packet's data (which may be considered layer seven). An 
NFS header may be considered a part of a packet's layer six protocol 
header or part of the packet's data. 

It is clear that the recitations of claims 6 and 26 are not met by the portions of 
Muller cited by the Final Rejection. Once again, the Final Rejection has failed at each of 
the factual inquiries required by Graham, as well as merely providing an unsupported and 
conclusory allegation of obviousness. 
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4. 



Claims 7 and 27 



Regarding claims 7 and 27, the Final Rejection states: 

As per claims 6, 26, Elzur, in view of Lot, does not explicitly 
discloses wherein said data is mapped form a logical file format of said 
file cache to a physical block format of the storage unit. 

However, the use and advantages for mapping is well-known to 
one of ordinary skill in the art as evidenced by Muller (column 50, lines 
49-52). 

Therefore, one of ordinary skill in the art at the time the invention 
was made would have found it obvious to implement or incorporate 
Muller's mapping in Elzur's device to lessen the flow key into a smaller 
range of values. 

Applicants respectfully disagree. For convenience, column 50, lines 49-52 of 

Muller is quoted below: 

Thus, in this embodiment only a six-bit 50 number is needed to 
identify the selected processor. The larger flow key-may therefore be 
mapped or hashed into a smaller range of values. 

It is clear that the recitations of claims 6 and 26 are not met by the cited portion of 
Muller. Once again, the Final Rejection has failed at each of the factual inquiries 
required by Graham, as well as merely providing an unsupported and conclusory 
allegation of obviousness. 



5. Claim 24 

Regarding claim 24, the Final Rejection states: 

As per claim 24, Elzur, discloses a Fibre Channel controller 
connectable to the storage unit (column 1, lines 18-20, column 3, lines 46- 
52). 

Applicants respectfully disagree. For convenience, the portions of Elzur cited by 

the Final Rejection are quoted in order below: 

More particularly, the physical layer 16e typically includes 
hardware (a network controller, for example) that establishes physical 
communication with the network 18 by 20 generating and receiving 
signals (on a network wire 9) that indicate the bits that make up the 
packets 8. 
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Referring to FIG. 4, an embodiment 50 of a computer system in 
accordance with the invention includes a network controller 52 (a local 
area network (LAN) controller, for example) that communicates packets 
of information with other networked computer systems via at least one 
network wire 53. Unlike conventional network controllers, the network 
controller 52 is adapted to perform functions that are typically 
implemented by a processor 54 (a central processing unit (CPU), for 
example) that executes one or more software layers (a network layer and a 
transport layer, as 55 examples) of a network protocol stack (a TCP/IP 
stack, for example). 

It is clear that the recitations of claim 24 are not met by the portions of Elzur cited 
by the Final Rejection. Once again, the Final Rejection has failed at each of the factual 
inquiries required by Graham, and does not even provide an unsupported and conclusory 
allegation of obviousness. 



6. Claim 28 

Regarding claim 28, the Final Rejection states: 

As per claim 28, Elzur discloses a method for operating an 
interface device for a computer having a file system that controls a file 
cache, the interface device connectable to a network and a storage unit, the 
method comprising: 

• Receiving, by the interface device from the network, a packet 
containing data and a Transmission Control Protocol (TCP) header 
(column 1, lines 18-21, column 2, lines 65-67, column 3, lines 1-3, 46-51, 
57-67, column 4, lines 1, 6-11 11, column 5, lines 63-66); 

• A memory storing a TCP connection established by the 
computer and handled by said device (column 4, lines 14-17, 23-25, 34- 
36, 61-67; column 5, lines 63-66, column 7, lines 1-5); 

• Processing, by the interface device, the TCP header (column 2, 
lines 64-67, column 4, lines 14-17, 23-25, 34-36, 61-67); 

• Associating, by the interface device, the packet with the TCP 
connection (column 4, lines 14-17, 23-25, 34-36, 61-67). 

Elzur does not explicitly disclose: 

• to send data from said packet via a second physical network 
port to a storage unit, thereby avoiding the computer. 

However in an analogous art, Lot discloses a packet switcher 
testing a physical address input port for availability to receive a packet of 
data. If available, the packet is transferred. The header of the packet 
determines process identification. Some data is transferred between user 
processes and buffers in the device, controller, or handler. However, a 
user process can initiate a transfer of data between source and destination 
without passing the data through the user's process. For example, a 
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transfer can go from a display record on disk to an operator station with no 
intervention from user and with direct routing of the data through the 
system. No processing occurs (column 17, lines 24-27, column 45, lines 
20-34, column 67, lines 49-55, column 68, lines 5-17, column 114, lines 
37-47). 

Therefore, one of ordinary skill in the art at the time the invention 
was made would have found it obvious to implement or incorporate Lot's 
send data via a second physical network port to a storage unit, thereby 
avoiding the computer in Elzur's device enabling data to be transferred 
without processing. 

Elzur, in view of Lot, does not explicitly disclose: 
• storing, on the interface device, the data from the packet in the 
file cache. 

However, the use and advantages for using such a file cache is 
well-known to one of ordinary skill in the art as evidenced by Muller 
(column 56, lines 20-30, column 57, lines 55-65, column 58, lines 26-30, 
column 59, lines 60-65). 

Therefore, one of ordinary skill in the art at the time the invention 
was made would have found it obvious to implement or incorporate 
Muller's file cache in Elzur's device in order to store non-assembled 
packets. 

Applicants respectfully disagree with this rejection for reasons similar to those 
mentioned above with regard to claim 1 . 

For example, the Final Rejection offers no evidence or argument for its allegation 
that "Elzur discloses a method for operating an interface device for a computer having a 
file system that controls a file cache." 

Similarly, the Final Rejection admits that "Elzur, in view of Lot, does not 
explicitly disclose... storing, on the interface device, the data from the packet in the file 
cache." The Final Rejection alleges that "such a file cache is well-known," citing Muller, 
but Muller also does not teach "storing the data from the packet in the file cache, wherein 
the file cache is disposed on the interface device." 

Further, the Final Rejection offers no interpretation of the terms of claim 28, and 
as such does not adequately compare the prior art with the claims. 

Moreover, the Final Rejection offers merely conclusory allegations of 
obviousness rather than comparing the claim as a whole with the prior art. 

For at least these reasons, applicants respectfully assert that the Final Rejection 
has failed to provide a prima facie case of obviousness for claim 28. 
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7. Claim 29 

Regarding claim 29, the Final Rejection states: 

As per claim 29, Elzur discloses the method of claim 28, further 
comprising creating, by the computer, the information regarding the TCP 
connection (column 4, lines 35-50). 

Applicants respectfully assert that column 4, lines 35-50 of Elzur does not 
disclose creating anything by the computer, but rather discloses items regarding the 
"network controller 52." 

The above rejection of claim 29 and applicants' above response are identical to 
the rejection of the prior Office Action and applicants' prior response. 

In this regard, the "Response to Arguments" section of the Final Rejection states: 
The Office notes the following argument(s): 

(c) Regarding claim 29, Elzur does not disclose creating anything 
by the computer. 

In response to: 

(c) Elzur teaches the receive path parses the header of each packet 
to extract characteristics of the packet. The packets may be from different 
flows and is stored in a memory. Each flow tuple uniquely identifies a 
flow pared by the receive path. At least one of the flow tuples may be 
associated with a TCP. This information is used to aid in transporting the 
packet to its proper destination (column 4, lines 31-51). 

Therefore, Elzur indeed discloses "creating, by the computer, 
information regarding the TCP connection". 

In other words, the Final Rejection simply ignores applicants' argument that the 
cited portion of Elzur does not disclose creating anything by the computer, but rather 
discloses items regarding the "network controller 52." Stated differently, the Final 
Rejection equates the "network controller 52" with the computer of claim 29, ignoring 
claim recitations and failing to perform the Graham factual inquiry of comparing the 
prior art with the claim. 



8. Claim 30 
Regarding claim 30, the Final Rejection states: 
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As per claim 30, Elzur discloses the method of claim 28, wherein 
the packet is received via the port and the data is sent to the storage unit 
via the port (column 4, lines 43-45, column 6, lines 49-50, column 11, 
lines 28-30). 

Applicants respectfully assert that none of these citations of Elzur disclose the 
recitation of claim 30, wherein the "port" is a "physical network port" as recited in claim 
28, from which claim 30 depends. 

The above rejection of claim 30 and applicants' response are identical to that of 
the prior Office Action and applicants' prior response. 

In this regard, the "Response to Arguments" section of the Final Rejection states: 
The Office notes the following argument(s): 

(d) Regarding claim 30, none of the citation of Elzur discloses the 
port as a physical port. 

(e) Regarding claim 31, None of the citations of Elzur disclose first 
and second physical network ports. 

In response to: 

(d)-(e) Elzur teaches packets containing destination and source port 
addresses. These port addresses indicates the specific source and 
destination computer systems that send and receive packets on the network 
(column 1, lines 51-67, column 2, lines 1-2, column 4, lines 39-44). 

Therefore, Elzur absolutely discloses first and second physical 
network ports. 

Applicants respectfully disagree with the Final Rejection assertion that "packets 
containing destination and source port addresses. . . indicates the specific source and 
destination computer systems." Instead, packet port numbers can indicate applications 
within a computer system, and well known port numbers are the same for different 
computer systems. Moreover, the Final Rejection does not provide an interpretation of 
the claim term "physical network port," failing at the Graham factual inquiry of 
comparing the prior art with the claim. 



9. Claim 31 
Regarding claim 3 1, the Final Rejection states: 
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As per claim 31, Elzur discloses the method of claim 28, wherein 
the interface device includes first and second network ports, and the 
packet is received via the first port and the data is sent to the storage unit 
via the second port (column 4, lines 43-45, column 6, lines 49-50, column 
11, lines 28-30). 

Applicants respectfully assert that none of these citations of Elzur disclose the 
recitation of claim 31, wherein "the interface device includes first and second physical 
network ports." 

The above rejection of claim 31 and applicants' response are identical to that of 
the prior Office Action and applicants' prior response, and the relevant "Response to 
Arguments" section of the Final Rejection is quoted above regarding claim 30. 

Applicants respectfully disagree with the Final Rejection assertion that "packets 
containing destination and source port addresses. . . indicates the specific source and 
destination computer systems." Instead, packet port numbers can indicate applications 
within a computer system, and well known port numbers are the same for different 
computer systems. Because "destination and source port addresses" are often the same 
for different computer systems, those port numbers do not indicate specific source and 
destination computer systems. Moreover, the Final Rejection does not provide an 
interpretation of the claim term "physical network port," failing at the Graham factual 
inquiry of comparing the prior art with the claim. 



10. Claim 32 
Regarding claim 32, the Final Rejection states: 

As per claim 32, Elzur, in view of Lot, does not explicitly discloses 
the method of claim 28, wherein said file cache is adapted to store said 
data as a file stream, and the interface device is adapted to send said data 
as file blocks for storage on the storage unit. 

However, the use and advantages for using such file cache to store 
and interface device to send data as blocks is well-known to one of 
ordinary skill in the art as evidenced by Muller (column 15, lines 19-25, 
column 16, lines 57-61, column 21, lines 27-34, 40-41, column 24, lines 
29-38). 

Therefore, one of ordinary skill in the art at the time the invention 
was made would have found it obvious to implement or incorporate 
Muller's file cache in Elzur's device in order to store non-assembled 
packets. 
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Applicants respectfully disagree. The portions of Muller cited by the Final 

Rejection are quoted in order below: 

For example, for a Network File System (NFS) application, data 
portion 202 may include NFS headers related to individual NFS 
datagrams. A datagram may be defined as a collection of data sent from 
one entity to another, and may comprise data transmitted in multiple 
packets. In other words, the amount of data constituting a datagram may 
be greater than the amount of data that can be included in one packet. 

Other indicia of the communicating entities may be used, such as 
the Ethernet source and destination addresses (drawn from the layer two 
header), NFS file handles or source and destination identifiers for other 
application datagrams drawn from the data portion of the packet. 

The Total Length field stores the size of the IP segment of this 
packet, which illustratively comprises the IP header, the TCP header and 
the packet's data portion. The TCP segment size of the packet (e.g., the 
size of the TCP header plus the size of the data portion of the packet) may 
be calculated by subtracting twenty bytes (the size of the IP version four 
header) from the Total Length value. After state 416, the illustrated 
procedure advances to state 422. 

In state 420, the values of the Payload Length (e.g., the size of the 
TCP segment) and Next Header field are saved, plus the IP source and 
destination addresses. 

For example, a set of instructions could be generated for parsing 
NFS (Network File System) packets. Illustratively, these instructions 
would be configured to parse layer five and six headers to determine if 
they are Remote Procedure Call (RPC) and External Data Representation 
(XDR), respectively. Other instructions could be configured to parse a 
portion of the packet's data (which may be considered layer seven). An 
NFS header may be considered a part of a packet's layer six protocol 
header or part of the packet's data. 

It is clear that the recitations of claim 24 are not met by the portions of Elzur cited 
by the Final Rejection. The present application, at page 8, line 3 1- page 9, line 9, 
describes sending the data from the file cache as file blocks for storage on the storage 
unit, stating: 

I/O driver 67 software operating on the host 20 under the file 
system interacts with controllers 64 and 72 for respective storage units 66 
and 70 to manipulate blocks of data, i.e., read the blocks from or write the 
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blocks to those storage units. Host file cache 24 and INIC file cache 80 
provide storage space for data that is being read from or written to the 
storage units 66 and 70, with the data mapped by the file system 23 
between the physical block format of the storage units 66 and 70 and the 
logical file format used for applications. Linear streams of bytes 
associated with a file and stored in host file cache 24 and INIC file cache 
80 are termed file streams. Host file cache 24 and INIC file cache 80 each 
contain an index that lists the file streams held in that respective cache. 

Moreover, the Final Rejection fails to provide an interpretation of the claim that 
might allow someone to understand how the cited portions relate to the claim. Once 
again, the Final Rejection has failed at each of the factual inquiries required by Graham, 
as well as providing an unsupported and conclusory allegation of obviousness, so that a 
prima facie case of obviousness is lacking. 



B. Claims 2, 5, 22 and 25 

Claims 2, 5, 22 and 25 stand rejected under 35 U.S.C. § 103(a) as allegedly being 
obvious over Elzur in view of Lotito in view of U.S. Patent No. 6,065,096 to Day et al. 
("Day"). 

1. Claims 2 and 22 
Regarding claims 2 and 22, the Final Rejection states: 

As per claims 2 and 22, Elzur, in view of Lot, discloses the 
interface device of claims 1 and 21. 

Elzur, in view of Lot, does not explicitly disclose the interface 
further comprising a SCSI controller connectable to the storage unit. 

However, Day discloses SCSI interface channels attached to disk 
drives (column 2, lines 40-54, column 5, lines 1-25). 

Therefore, one of ordinary skill in the art at the time the invention 
was made would have found it obvious to implement or incorporate in 
Day's interface comprising a SCSI controller in Elzur's device in order to 
provide for a simple, lower cost RAID controller architecture to enable 
lower cost and complexity associated with high performance and high 
reliability storage subsystems. 

Initially, applicants respectfully assert that, as discussed above, Elzur in view of 
Lotito does not disclose the interface device of claims 1 and 21 . Day does not mitigate 
the differences between Elzur in view of Lotito and those claims. For at least these 



Request for Reconsideration 
Application No. 09/675,700 



28 



reasons, applicants respectfully assert that claims 2 and 22 are nonobvious over the cited 
references. 



2. Claims 5 and 25 
Regarding claims 5 and 25, the Final Rejection states: 

As per claims 5 and 25, Elzur, in view of Lot, discloses the 
interface device of claims 1 and 21. 

Elzur, in view of Lot, does not explicitly disclose the interface 
further comprising a RAID controller connectable to the storage unit. 

However, Day discloses a RAID controller that integrates onto a 
single integrated circuit of a general-purpose processor (column 2, lines 
11-25,55-67). 

Therefore, one of ordinary skill in the art at the time the invention 
was made would have found it obvious to implement or incorporate Day's 
interface comprising a RAID controller in Elzur's device allowing the disk 
interface connections and protocols to be more flexibly selected but at the 
cost of less integration within the circuit. 

Initially, applicants respectfully assert that, as discussed above, Elzur in view of 
Lotito does not disclose the interface device of claims 1 and 21 . Day does not mitigate 
the differences between Elzur in view of Lotito and those claims. For at least these 
reasons, applicants respectfully assert that claims 5 and 25 are nonobvious over the cited 
references, and respectfully request favorable reconsideration and withdrawal of the 
rejection of claims 5 and 25 under 35 USC § 103. 

C. Claim 3 

Claim 3 stands rejected under 35 U.S.C. § 103(a) as allegedly being obvious over 
Elzur in view of Lotito in view of U.S. Patent No. 6,172,981 to Cox et al. ("Cox"). 
Regarding claim 3, the Final Rejection states: 

As per claim 3, Elzur, in view of Lot, does not explicitly discloses 
the interface device of claim 1, wherein said first network port is 
connected to a first network and said second network port is connected to 
a second network. 

However, in an analogous art, Cox teaches a switch that provides 
connection between different networks. The switch transmits data bits 
received from the source port directly to the destination port. It reads the 
network layer protocol header in a data frame, and if destined for a station 
on a different LAN segment, it transmits to the destination end station 
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(Abstract, column 1, lines 63-67, column 2, lines 1-5, 15-20, column 4, 
lines 3-8, column 5, lines 3-12). 

Therefore, one of ordinary skill in the art at the time the invention 
was made would have found it obvious to implement or incorporate Cox's 
ports on first and second networks in Elzur's device avoiding and 
eliminating delays by forwarding of data without storing the entire frame. 

Applicants respectfully assert that, as discussed above, Elzur in view of Lotito 
does not disclose the interface device of claim 1 . Cox does not mitigate the differences 
between Elzur in view of Lotito and that claim. For at least this reason, applicants 
respectfully assert that claim 3 is nonobvious over the cited references. 



III. Conclusion 

Applicants respectfully request favorable reconsideration and withdrawal of all of 
the rejections under §§ 103 and 1 12. For the reasons discussed above, applicants 
respectfully submit that all the claims are allowable, and a notice of allowance is 
solicited. 



Respectfully submitted, 



/Mark Lauer/ 

Mark Lauer 

Reg. No. 36,578 

Silicon Edge Law Group LLP 

6601 Koll Center Parkway 

Suite 245 
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